In computer science, the notion of recovery is fundamental to many areas: in database systems, transactions can be undone until they are “committed”; in applications, such as browsers and word processing applications, a button (or key combination) will undo recent actions; and in programming languages such as Interlisp, certain, but not all, operations may be available in a reversible form so that they can be undone through a built-in mechanism.
Generally, programs, as well as interactive systems, change the state of a system step-by-step. When a user of an interactive system discovers that a recent action was misinterpreted, or maybe mistakenly issued, it is useful if a single command can restore the state of the system to one that occurred before the erroneous action. Unfortunately, programming such a command is not an easy task using conventional programming languages, since the programmer must explicitly keep track of previous system states.
Therefore, it has been suggested to augment programming languages with constructs that enable the selective recovery of previous states. For example, Interlisp offers undoable versions of assignment statements that not only change the value of a variable in the conventional sense, but also preserves the previous value. When recovery is needed, the Interlisp language offers primitives that restore previous values of variables. Unfortunately, the recovery is partial, since it only works for variables that were modified exclusively through the undoable versions of operations.
It has also been suggested to build-in support for the undoability of all file related operations. The COPE system (see, James E. Archer, Jr., Richard Conway, and Fred B. Schneider; “User recovery and reversal in interactive systems,” ACM transactions on programming languages and systems, vol. 6, no. 1, January 1984) uses this approach for a uniform method of undoability. Changes in the COPE system are reflected in file changes, which are recorded and tracked. In particular, user interactions in a text editor all become undoable if the changes are committed to files. This approach, however, does not directly tie-in with the need for recovery of states expressed in the programming language that controls the more sophisticated user interfaces, such as those involving multimedia.
A more common approach to solving the issue of recovery in interactive systems is through the use of command encapsulation. Commands that are to be undone are equipped with a standardized interface, for example through the object-oriented technique of derivation, and these commands are invoked through a centralized component that keeps track on the sequence of commands executed. This method is described in “Design Patterns, Elements of Reusable Object-Oriented Software” by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison Wesley Professional Computing Series, p. 233. The command interface also allows for the specific formulation of the undo operation that can be invoked by the centralized component in case a previous state needs to be restored through the retraction of already executed commands. Moreover, it is natural to encapsulate state information with each instance of an executed command. In this way, important state information, chosen by the programmer, can be recovered by the centralized component when already executed commands are undone. One elaboration on this idea may be found in U.S. Pat. No. 5,481,710, Method of and System for Providing Application Programs Within Undo/Redo Function.